Security|Update Registry entry

Update the contents of one or more fields in the current record when the record is saved if a condition is met (a given value is in a field in the current record). Often (but not exclusively) used to modify Record Level Security security fields.

Note: This functionality is available in Vitalware 2.3 or later. Texpress 8.3.006 (or later) is required.

The Security Update Registry entry allows the contents of one or more fields to be modified whenever a record is saved (inserted or modified) based on the value in a field in the current record. Although any fields may be updated in this way, the Record Level Security (RLS) fields:

  • SecCanDisplay
  • SecCanEdit
  • SecCanDelete

are particularly useful as updating these allows the record security to be modified if a condition in the current record changes.

The database server applies the Security|Update settings whenever a record is saved (i.e. for all insertions and updates). The entries are applied after assignment expressions have been executed and before validation is run. This means that assignment expressions may be used to build a composite value that may be tested by Security|Update settings. For example, it is possible to concatenate two fields into one that may then be checked.

It is also possible to apply sophisticated formula to calculate a field to be checked. For example, you may want to set Security|Update Registry entries based on a range of years for a registration. You could use an assignment expression to set a value in a field based on the ranges:

Range

 Value
<1913 Public
1913-Today Embargoed

You may then use the values, Public and Embargoed in Security|Update Registry entries.

Note that you cannot use validation code to compute values as the Security|Update entries are applied before validation code is executed.

Usage

This Registry entry can be assigned to users and groups:

Key User User Group Group Group Group
Key 1 User User Group Group Group Group
Key 2 user user group group Default Default
Key 3 Table Table Table Table Table Table
Key 4 table Default table Default table Default
Key 5 Security
Key 6 Update
Key 7 column
Key 8 value
Value settings
User user Table table Security Update column value settings
User user Table Default Security Update column value settings
Group group Table table Security Update column value settings
Group group Table Default Security Update column value settings
Group Default Table table Security Update column value settings
Group Default Table Default Security Update column value settings

where:

column

defines which field should be consulted to look for a matching value.

When referencing an attachment field in a Security|Update Registry entry, it is necessary to use a field's Link Column name and a record's IRN. For example:

Key Setting Description
Key 1 Group  
Key 2 Admin  
Key 3 Table  
Key 4 ebirths  
Key 5 Security  
Key 6 Update  
Key 7 ChildPlaceOfBirthRef The attachment field is referenced as Key 7.
Key 8 9800 A record's IRN is required at Key 8.
Value SecRecordStatus=Deaccession  

When an attachment field is referenced as the Value, it is in the format Link Column name=IRN:

Key Setting
Key 1 Group
Key 2 Admin
Key 3 Table
Key 4 ebirths
Key 5 Security
Key 6 Update
Key 7 SecRecordStatus
Key 8 ^Deaccession$
Value ChildPlaceOfBirthRef =9800

value

is a Vitalware based search pattern.

If there is a match of the data in column with the value query, then the Registry entry is used and settings is applied.

Note: If column contains a table of values, each entry is checked against value.

Since value is a pattern, particular attention must be paid if you want to match the complete contents of a field.

For example, to match Registration but not Pending Registration, the pattern ^Registration$ should be used. It is important to remember that value operates in the same way as a Vitalware search term.

All comparisons of value are case insensitive.
settings

is a semicolon separated list of assignments to columns that is applied if there is a match of the data in column with the value query.

The format of settings is:

column=[+/-]term:[+/-]term:...;column=[+/-]term:...

where:

column

is the name of the column to be modified.

term

is the value to be set in column.

  • If term is preceded by a plus symbol (+), the value is added to the existing list of values.
  • If term is preceded by a minus sign (-), the value is removed from the existing list of values.
  • If no symbol precedes a term, the current contents of column are removed and replaced with term.
  • If more than one term is supplied for a given column, separated by colons (:), each term is applied one after the other.
  • If more than one column is to be modified, each set of column settings is separated by a semicolon (;).

If you specify a Security|Update Registry entry to limit the display of a record to group Admin if Record Status is changed to Retired for example, it is necessary to specify a Security|Update Registry entry to account for Record Status changing from Retired to some other condition (Active or null for instance). If no Security|Update Registry entry is specified to account for the change, changing the Record Status from Retired to some other condition will not update the security of the record.

Why?

We've only told Vitalware what to do if Record Status = Retired; we haven't told Vitalware what to do if Record Status no longer =Retired.

What does this mean?

If we only specify a Security|Update Registry entry to limit the display of a record to group Admin when Record Status = Retired, changing Record Status to anything other than Retired will not make the record available to other users.

If we want Record Level Security to be adjusted so that users in group Adoptions are the only ones allowed to view, edit and delete records that have a record status of Adoption, the following entry can be used:

Key Setting
Key 1 Group
Key 2 Default
Key 3 Table
Key 4 Default
Key 5 Security
Key 6 Update
Key 7 RecordStatusFlag
Key 8 ^A$
Value SecCanView=Group Adoption;SecCanEdit=Group Adoption;SecCanDelete=Group Adoption

Keys 7 and 8 indicate that the entry only applies where the RecordStatusFlag column matches the pattern ^A$ (i.e. where the field contains A only). If this is not the case, then the Registry entry is ignored. Where a record does match, the SecCanEdit field is set to group Adoption. As a leading plus or minus is not supplied, the contents of SecCanEdit are replaced with group Adoption. A similar update occurs for SecCanDelete and SecCanView.

A more complex example would involve removing edit access for all users in group Data Entry when a record is cancelled. Let's assume that the column RecOrdStatus contains the word cancelled for records that are no longer valid registrations. A suitable Registry entry would be:

Key

Setting
Key 1 Group
Key 2 Default
Key 3 Table
Key 4 ebirths
Key 5 Security
Key 6 Update
Key 7 RecOrdStatus
Key 8 ^cancelled$
Value SecCanEdit=-Group Data Entry

Notice how the terms to set have a leading minus sign, indicating the term (in this case the group name) is to be removed from the field SecCanEdit.

A third example requires all records with a print status of Ready to have group Counter removed and group Print added for both displaying and editing the record. The field containing the print status is ReadyToPrint. A suitable Registry entry is:

Key Setting
Key 1 Group
Key 2 Default
Key 3 Table
Key 4 epos
Key 5 Security
Key 6 Update
Key 7 ReadyToPrint
Key 8 ^Y$
Value SecCanDisplay=-Group Counter:+Group Print;SecCanEdit=-Group Counter:+Group Print

Notice how more than one field may be updated with a single Registry entry. Note also:

  • If a term has a leading plus symbol and the term already appears in the field, it is not added again.
  • Similarly, if a term has a preceding minus and it does not appear in the field, it is ignored.

In this final example we restrict the display privilege for records that have not been approved for viewing on the intranet to groups Admin, Registrations and Adoptions. Once the record has been approved for viewing on the intranet, we will allow all users to view the record. In this case two Registry entries are required:

  • The first restricts access for records not available on the intranet.
  • The second allows access to all users for record available on the intranet.

Suitable Registry entries are:

Key Setting
Key 1 Group
Key 2 Default
Key 3 Table
Key 4 ebirths
Key 5 Security
Key 6 Update
Key 7 AdmPublishWebPasswordFlag
Key 8 N
Value SecCanDisplay=Group Admin:+Group Registrations:+Group Adoptions
Key Setting
Key 1 Group
Key 2 Default
Key 3 Table
Key 4 ebirths
Key 5 Security
Key 6 Update
Key 7 AdmPublishWebPasswordFlag
Key 8 Y
Value SecCanDisplay=Group Default

Notice how the first term in the first Registry entry (Group Admin) does not have a leading plus or minus, meaning it replaces the current contents of SecCanDisplay. The following terms require a leading plus symbol otherwise they will also clear the current contents rather than adding to the first term. The second Registry entry replaces the contents of SecCanDisplay with group Default (this allows access for everyone).

By using a combination of Registry entries it is possible to produce quite sophisticated and dynamic privilege changes.